home *** CD-ROM | disk | FTP | other *** search
- Path: fido.asd.sgi.com!austern
- From: ark@research.att.com (Andrew Koenig)
- Newsgroups: comp.std.c++
- Subject: Re: FW: Inherent C++ problem?
- Date: 22 Jan 1996 09:37:21 PST
- Organization: AT&T Research, Murray Hill NJ
- Approved: austern@isolde.mti.sgi.com
- Message-ID: <DLHn9z.6qC@research.att.com>
- References: <01BAE696.8C249300@dino.int.com>
- NNTP-Posting-Host: isolde.mti.sgi.com
- X-Original-Date: Sat, 20 Jan 1996 16:32:22 GMT
- X-Auth: PGPMoose V1.1 PGP comp.std.c++
- iQBVAwUBMQPLYEy4NqrwXLNJAQF0zQH+NZTGvHMV5H9j46lW0fnnw/J2L4WY4ZLc
- LqqgRy8+gZT3obWV+xUtuqe1U8mi06K03piCqIIpOrD9ELCB7wMdqQ==
- =f/iA
- Originator: austern@isolde.mti.sgi.com
-
- In article <01BAE696.8C249300@dino.int.com> Eugene Lazutkin <eugene@int.com> writes:
-
- > Complex c( a+b );
-
- > In the last line 3 objects of type Complex are constructed instead of 1,
- > namely:
-
- > 1) Temporary Complex object constructed in 'operator +'
- > 2) Return value of 'operator +' copy-constructed from (1)
- > 3) 'c', copy-constructed from (2)
-
- > This is inefficient to the last extreme, moreover it cannot even be
- > optimized out since any copy-constructor can theoretically have non-local
- > side effects....
-
- But it can be optimized -- essentially the implementation is permitted
- to assume that the copy constructor does not have any important
- side effects. Moreover, lots of implementations perform this kind
- of optimization.
- --
- --Andrew Koenig
- ark@research.att.com
- ---
- [ comp.std.c++ is moderated. Submission address: std-c++@ncar.ucar.edu.
- Contact address: std-c++-request@ncar.ucar.edu. The moderation policy
- is summarized in http://dogbert.lbl.gov/~matt/std-c++/policy.html. ]
-